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METHOD FOR REDUCING COSTS DURING THE TRANSFER OF 
UNIDIRECTIONAL INFORMATION FLOWS 

CROSS REFERENCE TO RELATED APPLICATIONS 
[0001] This application is the US National Stage of International Application No. 
PCT/EP2004/052630, filed October 22, 2004 and claims the benefit thereof. The 
International Application claims the benefits of German application No. 10350353.6 DE 
filed October 29, 2003, both of the applications are incorporated by reference herein in 
their entirety. 

FIELD OF INVENTION 

[0002] The invention relates to a method for reducing costs of processing useful data 
transferred in the direction of a communication device in cases in which a bidirectional 
connection between the communication device and a communication partner entity is set 
up within the framework of a service, although the service does not require transmission 
of useful data to the communication device. 

[0003] The invention lies in the area of voice and data communication and in 
particular touches on aspects of switching technology. 

BACKGROUND OF INVENTION 

[0004] In communication technology there is constant striving for resource efficiency. 
In such cases making savings in communication devices for switching and distribution of 
useful data has an important role to play. When reducing the costs and the complexity of 
these types of devices however it should be considered that standards have to be 
complied with and the compatibility to other communication devices is to be preserved. 
These requirements frequently get in the way of reducing the means or resources used. 

SUMMARY OF INVENTION 
[0005] An important example for communication devices with a potential for savings 
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are devices of which the functionality does not demand any processing of incoming 
useful data. Examples of these types of communication devices are as follows: 

• Pure information output systems, e.g. pure voice response systems. For information 

output systems which only provide for the output of information (e.g. voice 
information) and may possibly not be able to be controlled by information fed in 
from outside (such as systems for interactive voice response) the resources for 
processing of information transferred to the system can be reduced. 

• Pure distribution systems. Distribution systems are frequently restricted to the 

forwarding of or onwards transfer of information or useful data. Resources for the 
interpretation or processing of useful data can be provided to a reduced extent. 

[0006] The saving measures described above are restricted by the fact that there must 
be compatibility in communication with other devices or terminals. Thus there are 
communication entities (e.g. terminals, switching devices or gateways), for which 
bidirectional communication is provided within the framework of a communication 
process regardless of whether useful data is actually being sent to the communication 
partner entity. For connections for useful data transmission to this type of communication 
entity resources must be provided by information output systems or communication 
distribution systems for processing the information transferred by the communication 
partner entity, in order to make possible a bidirectional connection. 

[0007] An example for this type of scenario is the exchange of information between a 
pure voice response system and a terminal in which only a bidirectional connection is 
supported by the terminal. Although relevant information is only transferred in one 
direction (from the voice response system to the terminal) a transmission of useful data in 
the other direction also arises, which consists for example of the transmission of 
background noises picked up by a microphone of the terminal. The useful data flow or 
bearer flow transmitted from the terminal to the voice response system is then irrelevant 
for the service but demands processing resources on the voice response system side. 

[0008] In addition the protocols used for a bidirectional connection frequently provide 

2003P16444WOUS Clean Substitute Specification JDH.rtf 
2 of 9 



Attorney Docket No. 2003P16444WOUS 



for information to be sent in both directions which contains statistical data about the 
quality of the connection. This information is used for example to regulate the 
transmission rate. A communication device involved must thus have the means to 
generate this information. 

[0009] An important protocol in which the situation described above can occur is the 
RTP (real time protocol) which is used in connection with the RTCP (real time control 
protocol). The RTP protocol makes it possible to transmit voice as useful data or bearer. 
The transmission of the bearer is controlled by the RTCP protocol. If for example a voice 
response system outputs voice information by means of the RTP/RTCP protocol stack to 
a terminal which only supports bidirectional RTP connections, statistical information 
about the connection is transferred in both directions by means of the RTCP protocol. 

[0010] An object of the invention is to make possible a reduction in costs for 
communication devices. 

[0011] The object is achieved by the objects of the independent claims. 

[0012] The invention is based on the observation that for communication devices 
which in general or for specific services do not provide for transmission of useful data to 
a communication partner entity, in cases in which despite this a bidirectional connection 
to the partner entity is set up, for example because the communication partner entity only 
supports bidirectional connections with the protocol used, the cost of processing of the 
useful data transferred by the communication partner entity can be reduced by discarding 
at least a part of this useful data transmitted by the communication partner entity in the 
direction of the communication device. 

[0013] Examples of devices or services for which as a rule useful data transmission is 
only provided in one direction, i.e. unidirectionally, are information output systems (e.g. 
voice response systems) and distribution systems or information output services (e.g. 
voice response services) and distribution services. The communication partner entity can 
for example take the form of a terminal or a gateway. 
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[0014] The invention has the advantage of greater resource efficiency compared to 
conventional systems. The cost of processing is reduced by transmitted useful data which 
is irrelevant for the service being discarded. An irrelevant background noise which may 
possibly be transmitted for a voice connection is not completely evaluated in the 
communication device. Savings can be made in some of the hardware or software 
resources which are conventionally provided in the communication device for processing 
of useful data transmitted to the communication device This can involve expensive 
special hardware such as DSPs (DSP: digital signalling processor) or ASICs (ASIC: 
application specific integrated circuit). 

[0015] The invention can for example be used in packet-oriented networks over which 
useful data is transmitted as useful data packets in the direction of the communication 
device. In this case the discarding of the packets can be implemented for example in the 
following two ways: 

• A router upstream from the communication device discards the useful data transmitted 

to the communication device. 

• Incoming data packets are filtered in the communication device, e.g. on the basis of 

the UDP port addresses (UDP: user datagram protocol), and useful data packets 
which were sent by the communication partner entity are discarded. This filtering 
out of the useful data not relevant for the service can be undertaken on the lower 
layers of the protocol stack. Processing on the upper layers of the communication 
protocol or an evaluation or interpretation of transferred useful data is not required, 
so that no resources have to be provided for this. 

[0016] The useful data packets are transmitted for example in the case of real-time 

traffic by means of the RTP protocol. The RTCP protocol is used for the control of RTP 

connections. In accordance with the RTCP protocol statistical information is transmitted 

between the communication entities which frequently relates to the transmission quality 
» 

of the useful data transmission of the communication entities. Conventionally the 
generation of such statistical information or in general of control information on 
connection quality requires the transferred useful data to be evaluated. The present 
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invention however provides for part of the useful data to be discarded in the cases 
discussed, that is not evaluated in relation to transmission quality. In accordance with an 
advantageous development the control partner entity can be prevented, on account of 
missing or misleading messages or information about the connection established to a 
communication device, from initiating undesired reactions - in the extreme case the 
ending of the bidirectional connection. In this case the communication device sends 
information or messages to the communication partner entity which simulate a correct 
functioning of the useful data transmission from the control partner entity to a 
communication device. In this case for example a known range of values for the control 
information can be used which corresponds to a trouble-free useful data transmission. 
Furthermore it is possible for a small part of the useful data not to be discarded but to be 
evaluated for the calculation of statistical information or control information and for the 
results obtained to be extrapolated for the entire volume of useful data. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0017] The invention is explained in greater detail below within the context of an 
exemplary embodiment with reference to Figures. The Figures show: 

Figure 1 : a communication device and a communication partner entity which 

communicate with one another, with useful data transmitted from a 
communication partner entity to the communication device being 
filtered out by a router. 

Figure 2: a communication device and a communication partner entity in a 

communication relationship, with the useful data sent from the 
communication partner entity to the communication device being 
filtered out in the communication device and discarded. 

DETAILED DESCRIPTION OF INVENTION 

[0018] Both Figures show a communication device IVR (IVR: Interactive Voice 
Response) and a communication partner entity KPI which exchange useful data with each 
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other via a bidirectional connection by means of the RTP protocol. These connections are 
controlled or checked by means of the RTCP protocol. A router R is shown in Figure 1 
which filters out with the aid of a filter F useful data transmitted to the communication 
device IVR, so that this data does not reach the communication device IVR. In Figure 2 
this filter function is undertaken by the communication device IVR itself which filters out 
useful data transmitted from the communication partner entity KPI with the aid of a filter 
F and discards it, so that said data does not have to be processed by higher protocol 
layers. 

[0019] The communication device IVR is for example a software-based VoIP (VoIP: 
Voice over IP) voice response system based on the RTP and the RTCP protocol. 

[0020] An example is described below for a voice response system showing how it is 
possible to work with unidirectional channels instead of with bidirectionally operated 
RTP/RTCP channels. 

[0021] In the first example corresponding to Fig. 1 an upstream router discards the 
RTP packets in the direction of the voice response system, so that despite bidirectional 
through connection, no RTP load is imposed on the voice response system. 

[0022] In the case in which the useful data is handled in the voice response system 
(example corresponding to Fig. 2) the Call Controller controlling the call or the remote 
end point switches a symmetrical RTP flow through the IP network to the voice response 
system. A static filter is created above the IP stack, i.e. the IP protocol stack in the voice 
response system, which detects and discards all IP packets leading to the voice response 
system transmitted by means of the RTP protocol on the basis of the UDP (user datagram 
protocol) ports used by these protocols. The higher protocol layers which would have had 
to execute the tasks for these packets requiring more computing time therefore no longer 
have any load imposed on them and only have to handle outgoing data flows. 

[0023] Since in a software-based voice response system a very high proportion of the 
performance is expended in handling RTP protocol sequences, the freed-up computing 
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time budget can now be used for example for handling further voice response ports. 

[0024] RTCP sender reports are sent out in the way provided for in RFC 1 889 (RFC: 
request for comments). The standard already provides for these to be sent out relatively 
infrequently so that no major outlay in computing time is required. Thus the filter can 
forward RTCP packets to the RTCP protocol stack of the voice response system. 

[0025] In accordance with a development of the subject of the application the correct 
functioning of a bidirectional connection can be simulated at the level of the RTCP 
protocol. The RTCP protocol provides for the optional sending out of what are known as 
Receiver Reports from the voice response system to the remote user. Since in the 
exemplary embodiment a bearer or useful data flow is physically switched by the IP 
network, an attempt can be made to evaluate the voice flows or Voice Activity messages 
picked up by the remote microphone and transmitted via the communication partner 
entity to simulate to the remote user or to its bearer treatment a duplex dream, i.e. a 
bidirectional connection. 

[0026] So that the aim of reducing costs which is achieved by an exemplary 
embodiment is not counteracted, it makes sense to dispense with continuous calculation 
of the RTCP statistics based on all received RTP packets. The following approaches to 
solutions for reducing the effort of calculating the RTCP statistics can be adopted: 

[0027] a) Sending out a default Reception Report 

[0028] Since a voice response or distribution system described here is not dependent 
on the quality of the flow received, experience shows that acceptable default values can 
be entered in the report. If a network operator is to evaluate or interpret these, he must be 
aware of the fact that specifically these reports are not meaningful merely within the 
framework of the definition of the default values. This ensures that the remote bearer 
treatment does not initiate any undesired counter-measures (e.g. reduces the send rate or 
generates error reports). The Reception Report can contain the following parameters (in 
accordance with RFC 1889): 
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• SSRC (Synchronization source) of the sending source (can be determined from any 

received RTP packets, e.g. by means of an RTP sniffer or filter, which at least 
evaluates a number of packets at the beginning of the call/the session or is 
determined from the last received emitter report) 

• Lost Fraction : 256 is entered here, which corresponds to an ideal reception. 

• Cumulated number of lost packages: 0 or a very low value is entered here. 

• Highest received sequence number: The number of Sequence Number Cycles and the 

Highest Sequence Number Received is determined from a rounding of an 
algorithmic calculation from 

- the time since the last Reception Report (alternately the beginning of the bearer 
through-connection can be used as a basis) 

- the Codec Type and its bandwidth and 

- the packetization sizes used (results of the Codec Negotiation) 

by means of the RTP packet number to be expected. These parameters are stable for 
voice response systems for each call/session and therefore this type of 
calculation/sequence of divisions is possible. 

• Interarrival Jitter: a non-suspect value which corresponds to 1 ms is entered here. 

• Last (arrived) SR: The time stamp of the last send report is transferred from the RTCP 

statistics function for Sender Reports. 

• Delay since last (arrived) SR: The delay entered in the last send report is transferred 

from the RTCP statistics function for Sender Reports. 

[0029] b) Reduction of the number of RTP packets which have to be processed by the 
RTCP statistics function. 

[0030] Checked via a suitable time-controlled dynamic filter above the IP stack 
(which is sensitive to RTP port addresses), the RTCP statistics function is only presented 
with RTP packets over a restricted period of time (e.g. the duration of a voice response 
call), e.g. over a number of equally-distributed 100 ms intervals of the voice response call 
which lasts an average of 10 seconds. The RTCP ports are in principle open here. 
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[0031] Essentially commercial RTCP statistics can be reused here which feign a 
longer measurement than has actually taken place. The parameter "Highest Received 
Sequence Number" must however be approximated as under a). For the "Interarrival Jitter 
and Lost Fraction" parameters on the other hand the values generated from the 100 ms 
measurement can be entered as the "real" measured values in the Reception Report. The 
parameter "Cumulated number of lost packages" must also be extrapolated. 

[0032] If for example intervals lasting 1 second are used as the basis for sending out 
the Reception Reports and only 100 ms is measured in them in each case, the value to be 
sent would have to be multiplied by a factor of 10. An equal distribution of packet losses 
over the duration of the call is assumed here. 
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